Skip to content

refactor: Build RBAC with recommended labels#846

Open
adwk67 wants to merge 7 commits into
mainfrom
feat/smooth-operator/build-rbac
Open

refactor: Build RBAC with recommended labels#846
adwk67 wants to merge 7 commits into
mainfrom
feat/smooth-operator/build-rbac

Conversation

@adwk67

@adwk67 adwk67 commented Jul 20, 2026

Copy link
Copy Markdown
Member

Description

Part of: stackabletech/issues#869

Definition of Done Checklist

  • Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
  • Please make sure all these things are done and tick the boxes

Author

  • Changes are OpenShift compatible
  • CRD changes approved
  • CRD documentation for all fields, following the style guide.
  • Helm chart can be installed and deployed operator works
  • Integration tests passed (for non trivial changes)
  • Changes need to be "offline" compatible
  • Links to generated (nightly) docs added
  • Release note snippet added

Reviewer

  • Code contains useful comments
  • Code contains useful logging statements
  • (Integration-)Test cases added
  • Documentation added or updated. Follows the style guide.
  • Changelog updated
  • Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

  • Feature Tracker has been updated
  • Proper release label has been added
  • Links to generated (nightly) docs added
  • Release note snippet added
  • Add type/deprecation label & add to the deprecation schedule
  • Add type/experimental label & add to the experimental features tracker

@adwk67 adwk67 changed the title factor: add infallible rbac functions refactor: Build RBAC with recommended labels Jul 20, 2026
Base automatically changed from feat/smooth-operator/introduce-builder to main July 21, 2026 15:17
@adwk67 adwk67 self-assigned this Jul 21, 2026
@adwk67
adwk67 force-pushed the feat/smooth-operator/build-rbac branch from 335474d to 3e60002 Compare July 21, 2026 16:00
@adwk67

adwk67 commented Jul 23, 2026

Copy link
Copy Markdown
Member Author
--- PASS: kuttl (488.81s)
    --- PASS: kuttl/harness (0.00s)
        --- PASS: kuttl/harness/smoke_druid-37.0.0_zookeeper-3.9.5_hadoop-3.5.0_openshift-false (488.80s)
PASS

Comment on lines 60 to 62
/// `service_account_name` is the name of the RBAC `ServiceAccount` the role-group Pods run under
/// (RBAC resources are built and applied separately, in the reconcile step).
///

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@adwk67 adwk67 Jul 23, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't apply this and I'm not sure what it is referring to.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put each new sentence on a new line, in case that was what was meant.

Comment on lines +200 to +204
/// The type-safe role name for a Druid role.
pub(crate) fn role_name(role: &DruidRole) -> RoleName {
RoleName::from_str(&role.to_string())
.expect("a DruidRole always serializes to a valid role name")
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This role_name function is cumbersome to use:

// &DruidRole → &RoleName
&ValidatedCluster::role_name(role)

If we add implementations for From right next to DruidRole

impl From<DruidRole> for RoleName {
    fn from(value: DruidRole) -> Self {
        RoleName::from_str(&value.to_string()) Result<RoleName, Error>
            .expect("a DruidRole always serializes to a valid role name")
    }
}

impl From<&DruidRole> for RoleName {
    fn from(value: &DruidRole) -> Self {
        RoleName::from_str(&value.to_string()) Result<RoleName, Error>
            .expect("a DruidRole always serializes to a valid role name")
    }
}

then it would become:

// &DruidRole → &RoleName
&role.into()

If we add a Deref<Target = RoleName> for DruidRole

stackable_operator::constant!(COORDINATOR_ROLE_NAME: RoleName = "coordinator");
stackable_operator::constant!(BROKER_ROLE_NAME: RoleName = "broker");
stackable_operator::constant!(HISTORICAL_ROLE_NAME: RoleName = "historical");
stackable_operator::constant!(MIDDLE_MANAGER_ROLE_NAME: RoleName = "middlemanager");
stackable_operator::constant!(ROUTER_ROLE_NAME: RoleName = "router");

impl Deref for DruidRole {
    type Target = RoleName;

    fn deref(&self) -> &Self::Target {
        match self {
            DruidRole::Coordinator => &COORDINATOR_ROLE_NAME,
            DruidRole::Broker => &BROKER_ROLE_NAME,
            DruidRole::Historical => &HISTORICAL_ROLE_NAME,
            DruidRole::MiddleManager => &MIDDLE_MANAGER_ROLE_NAME,
            DruidRole::Router => &ROUTER_ROLE_NAME,
        }
    }
}

then it would be completely transparent for the user:

// &DruidRole → &RoleName
role

In this case, ValidatedCluster::recommended_labels can be removed.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This role_name function is cumbersome to use:

It was a one-liner! I've replaced it with the better one-liner, but I'm not so convinced about the deref: it seems like a lot of code to add for something simple, and ValidatedCluster::recommended_labels can be moved to operator-rs in a later step anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants